INTPYTHON-821 Add workflow to update SBOM #451

thanhnguyen-mdb · 2025-11-21T17:12:40Z

Summary

Added in Github action workflow for SBOM automation. This triggers on changes to any of the requirements and toml files on the master branch. A new branch will be created for the PR and closed on merge.

Sample PR for the SBOM: thanhnguyen-mdb#4

Changes in this PR

New sbom.yml file for the Github action workflow

Testing Plan

Tested through Github Action triggers

Checklist

Checklist for Author

Did you update the changelog (if necessary)?
Is the intention of the code captured in relevant tests?
If there are new TODOs, has a related JIRA ticket been created?

Checklist for Reviewer {@primary_reviewer}

Does the title of the PR reference a JIRA Ticket?
Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
Have you checked for spelling & grammar errors?
Is all relevant documentation (README or docstring) updated?

thanhnguyen-mdb · 2025-11-24T15:51:13Z

Need to update this to use cyclonedx-py plugin instead. Will move to ready review once finish.

aclark4life

LGTM!

timgraham · 2025-12-03T15:18:02Z

You write that "This triggers on changes to any of the requirements and toml files on the master branch.", however, it's also obsoleted whenever a new version of pymongo or Django is released that matches the requirements. For example, we have the dependency "django>=5.2,<6.0" and generally a new version of Django 5.2.x is released each month. Does the SBOM need to be updated each time?

.github/workflows/sbom.yml

timgraham · 2025-12-03T15:28:30Z

.github/workflows/sbom.yml

+    paths:
+      - 'pyproject.toml'
+      - 'requirements.txt'


It's possible for these files to have changes that don't involve any dependency changes. Is there logic in this job that prevents a PR from being opened in this case? (I guess GitHub may disallow a PR with no changes, or possibly it would be closed immediately; just want to confirm.)

I'm not sure myself, but I would say that if it:

Has no changes, it wouldn't populate

Does make a new one, we just close it. The SBOM generation matters most right before we push a release.

Depending on the answer to #451 (comment), it might be better to simply make this part of the pre-release process.

If the file changes at all, it will trigger the action to run and make an sbom PR. you'd just see the dates/metadata of the sbom.json to be changed. In that scenario the team can just close the PR.

Our team does require that the master branch have an up-to-date sbom for tracking. I can definitely add the logic if you think it's worth the extra step (actions will still get ran regardless, but we'd just compare the sbom files to see if any components actually got changed)

If it's straightforward, I think it would be valuable to avoid useless PRs, especially if this script has to be applied to many repositories.

And incidentally, we don't have any dependencies in pyproject.toml (besides the optional ones for building the docs which your script doesn't install, so won't be detected anyway) so do we need to have this job watch that file?

pyproject.toml stores the info for the actual django-mngodb-backend. Changes to meta data will be reflected into sbom (description, versions, etc). With the new check for component diff check, this should solve the false positive change issue if you're modifying something that won't update the sbom.

Just to clarify: we do have dependencies in pyproject.toml. The fact that pyproject.toml is configured to read requirements.txt via tool.hatch.metadata.hooks.requirements_txt is an implementation detail. In fact, we may want to consider moving those dependencies to pyproject.toml and removing requirements.txt because we have so few dependencies and don't really need a separate file to list them.

@thanhnguyen-mdb FYI, see what pymongo did: mongodb/mongo-python-driver#2647 removing pyproject.toml from the watched paths). If I understand correctly, maybe it would have been better to use the alternative approach you implemented here (although I'm not sure if there's any practical difference).

.github/workflows/sbom.yml

thanhnguyen-mdb · 2025-12-03T18:22:25Z

You write that "This triggers on changes to any of the requirements and toml files on the master branch.", however, it's also obsoleted whenever a new version of pymongo or Django is released that matches the requirements. For example, we have the dependency "django>=5.2,<6.0" and generally a new version of Django 5.2.x is released each month. Does the SBOM need to be updated each time?

The SBOM doesn't become stale when new patch versions are released. The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available. The workflow triggers only when dependency specifications actually change in the requirements files (based on what runtime users would install). When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

It does become stale in release branch if you are making one off requirements change in those branch though if that's what you're referring to? If that's the case then those branch sbom would need to be updated as well.

.github/workflows/sbom.yml

timgraham · 2025-12-03T19:29:32Z

The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available.

This doesn't seem true. In thanhnguyen-mdb#4, I see a refernce to "Django==5.2.8" which was the latest Django release at the time that job ran.

When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

You'll have to explain more about how this works. Our release process doesn't use release branches. Currently, the main branch corresponds to Django MongoDB Backend 5.2.x which works with Django 5.2.x. We have for older versions, e.g. the 5.1.x corresponds to Django MongoDB Backend 5.1.x and Django 5.1.x.

thanhnguyen-mdb · 2025-12-03T19:42:56Z

The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available.

This doesn't seem true. In thanhnguyen-mdb#4, I see a refernce to "Django==5.2.8" which was the latest Django release at the time that job ran.

Sorry, got info a bit mixed up. It's the minimum version/installed version when a user runs pip install -r requirements.txt (runtime version for their python version).

When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

You'll have to explain more about how this works. Our release process doesn't use release branches. Currently, the main branch corresponds to Django MongoDB Backend 5.2.x which works with Django 5.2.x. We have for older versions, e.g. the 5.1.x corresponds to Django MongoDB Backend 5.1.x and Django 5.1.x.

Ah that makes more sense then! If I make it trigger a PR on master/release branch (5.1.x, etc), would that suffice then? This would be a bit more PR but will keep all branch updated. Welcome to suggestions here.

I'll add extra logic to avoid false positive PR in the meantime.

timgraham · 2025-12-03T20:10:32Z

Here's how I foresee this script working:

We bump the main branch to Django 6.0, so SBOM is updated for Django 6.0, the current version of pymongo, and the current versions of the dependencies of these libraries.
We likely won't update requirements.txt for the rest of Django 6.0.x, however, in the meantime Django 6.0.1, Django 6.0.2, etc. will be released monthly, some which may contain security fixes. Is it important to have the SBOM include these updates or no?
Say we did add some dependency in requirements.txt (or even make some unrelated change in pyproject.toml, say a new version of Python is released and we add the trove classifier in pyproject.toml). That will invoke this job and cause the SBOM to update Django 6.0 and the other packages to their newest versions.

It seems very arbitrary to make these sort of updates based on when changes to these files are made. Do you see my point?

timgraham · 2025-12-03T20:12:13Z

Ah that makes more sense then! If I make it trigger a PR on master/release branch (5.1.x, etc), would that suffice then? This would be a bit more PR but will keep all branch updated. Welcome to suggestions here.

It doesn't seem correct. An update to the dependencies on the main branch doesn't mean they changed on other branches.

thanhnguyen-mdb · 2025-12-05T16:08:19Z

@timgraham I've added in the update as discuss yesterday. Will now only do PRs if the sbom content actually changes by using cyclondx-cli tool diff options on components. See here for a test run in my fork:
https://github.com/thanhnguyen-mdb/django-mongodb-backend/actions/runs/19968310880/job/57265977438

I've also tested on a diff branch trigger to make sure PR submits to that branch: thanhnguyen-mdb#9

This PR only has main for now. Please add new release versions to it that you want to track later. Let me know if you need any other changes

timgraham · 2025-12-17T16:43:24Z

.github/workflows/sbom.yml

+on:
+  workflow_dispatch: {}
+  push:
+    branches: ['main', '5.2.x']


I added the 5.2.x branch here, but I'm not sure if it works correctly. Will the job checkout this branch and send the PR to it?

aclark4life requested a review from timgraham November 21, 2025 17:20

Jibola requested review from Jibola and removed request for timgraham November 21, 2025 18:45

timgraham changed the title ~~INTPYTHON-821 - Added SBOM update automation~~ INTPYTHON-821 Add SBOM update automation Nov 22, 2025

thanhnguyen-mdb marked this pull request as draft November 24, 2025 15:49

thanhnguyen-mdb marked this pull request as ready for review November 24, 2025 16:24

aclark4life requested a review from timgraham December 1, 2025 15:58

Jibola requested a review from aclark4life December 2, 2025 18:40

aclark4life approved these changes Dec 3, 2025

View reviewed changes

timgraham reviewed Dec 3, 2025

View reviewed changes

github-advanced-security bot found potential problems Dec 3, 2025

View reviewed changes

.github/workflows/sbom.yml Fixed Show fixed Hide fixed

github-advanced-security bot found potential problems Dec 3, 2025

View reviewed changes

.github/workflows/sbom.yml Fixed Show fixed Hide fixed

github-advanced-security bot found potential problems Dec 3, 2025

View reviewed changes

.github/workflows/sbom.yml Fixed Show fixed Hide fixed

thanhnguyen-mdb force-pushed the sbom branch from 43bf70f to 67deeee Compare December 5, 2025 15:46

aclark4life mentioned this pull request Dec 10, 2025

PYTHON-5673 Only update sbom when core dependencies change mongodb/mongo-python-driver#2647

Merged

6 tasks

Jibola approved these changes Dec 16, 2025

View reviewed changes

INTPYTHON-821 Add workflow to update SBOM

1e53067

timgraham force-pushed the sbom branch from 67deeee to 1e53067 Compare December 17, 2025 15:41

timgraham changed the title ~~INTPYTHON-821 Add SBOM update automation~~ INTPYTHON-821 Add workflow to update SBOM Dec 17, 2025

timgraham reviewed Dec 17, 2025

View reviewed changes

INTPYTHON-821 Add workflow to update SBOM #451

Are you sure you want to change the base?

INTPYTHON-821 Add workflow to update SBOM #451

Conversation

thanhnguyen-mdb commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes in this PR

Testing Plan

Checklist

Checklist for Author

Checklist for Reviewer {@primary_reviewer}

Uh oh!

thanhnguyen-mdb commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aclark4life left a comment

Choose a reason for hiding this comment

Uh oh!

timgraham commented Dec 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timgraham Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

thanhnguyen-mdb commented Dec 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

timgraham commented Dec 3, 2025

Uh oh!

thanhnguyen-mdb commented Dec 3, 2025

Uh oh!

timgraham commented Dec 3, 2025

Uh oh!

timgraham commented Dec 3, 2025

Uh oh!

thanhnguyen-mdb commented Dec 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

thanhnguyen-mdb commented Nov 21, 2025 •

edited

Loading

thanhnguyen-mdb commented Nov 24, 2025 •

edited

Loading

timgraham Dec 16, 2025 •

edited

Loading